NMS-9350: Add support for Kerberos message encryption - #32

Couple things that seem like blockers (via claude though I've also looked as much as I can and I think these are all valid).

KerberosDecryptInInterceptor.handleMessage returns early when the body doesn't start with --Encrypted Boundary, so a plaintext SOAP response is accepted.

Also, neither wrap nor unwrap inspects the MessageProp afterwards: getPrivacy() is never checked, so an integrity-only token is accepted as confidential in both directions, and isDuplicateToken/isOldToken/isUnseqToken/isGapToken are discarded, throwing away GSS replay detection. With withKerberosEncryption() on, a non-multipart or non-private response has to be a hard failure.

One GSSContextManager per operation, with correctness resting on a JVM-global socket pool. getIdentifier/getEnumerator/getTransferer each call createProxyFor, which constructs a fresh manager, so every identify/enumerate/pull/get runs its own full AP-REQ/AP-REP pre-flight. The encrypted POST then has to land on the exact TCP connection that that manager's handshake bound, but the HttpURLConnection keep-alive pool is keyed only by (host, port, SSLSocketFactory) and hands out any idle socket. Sequential use mostly works because the latest handshake rebinds the single idle socket; two threads sharing a CXFWSManClient can get each other's session. None of these contexts is ever disposed either.

Minor but I think this is worth doing.

I think this is good!

The PR adds tlsParams.setSSLSocketFactory(buildPermissiveSslSocketFactory()) next to the existing setTrustManagers(trustAll).

• HttpsURLConnectionFactory.decorateWithTLS:130 — when an SSLSocketFactory is set, CXF uses it and ignores the trust managers, cipher-suite filter and secureSocketProtocol. The trustAll array two lines above is now dead config.
• HttpClientHTTPConduit.setupConnection:352 — an explicit SSLSocketFactory forces CXF off the Java 11 HttpClient conduit back onto the legacy HttpURLConnection conduit, for every strictSSL=false HTTPS endpoint.

The Kerberos path never reads TLSClientParameters at all - KerberosHttpConduit.setupConnection() is a no-op and the session gets its own factory at CXFWSManClient.java:401. So these two lines buy the feature nothing and silently change transport behaviour for the mainstream iDRAC/WinRM-over-HTTPS users. Also builds a fresh SSLContext per operation, losing TLS session resumption. Recommend simply deleting both calls.

LGTM.